Software programmers have difficulty preparing code for hardware that has not yet completed a design stage. Debugging software coding for undeveloped hardware is nearly impossible to do with a high level of confidence that the debugged software will function properly on a prototype version of the hardware under development. Conventional approaches involve waiting to run tests against a hardware device (i.e., silicon) to see how the software operates. When the hardware is available, the tests are applied to the prototype silicon and the results are compared. If there are defects in the software code, much time is wasted in the development stage waiting for functional software to be developed after the hardware is ready.
A second conventional approach is to develop a hardware model (i.e., a field programmable gate array) of the hardware device under development with which code debugging tests are run before the silicon is ready. Such tests include sort tests, class tests, and tests using evaluation boards. The tests are generally developed blindly before the hardware is available. When the silicon version of the hardware is ready, the tests are applied to the silicon hardware.
A third conventional approach involves developing a software model (i.e., register transfer language (RTL) simulation) with which to run functional tests before a prototype of the silicon is ready. Functional tests are then applied when the silicon is ready. Following the functional tests, a simulation versus silicon analysis is performed to see if the silicon behaves in the same manner as the simulations and if the code written is functional with the prototype. If the test fails, debugging/comparing the results of the functional simulations and silicon operation can be time consuming and error prone.
Disadvantages of the conventional approaches include spending a considerable amount of time debugging software tests. Time elapses before the tests are sufficiently debugged to be helpful to the developer. The developer may have to wait until a hardware prototype is available before debugging the software. Waiting for the hardware presents a bottleneck in the silicon characterization process, delays product release and is a competitive disadvantage. Additionally, errors often arise in developing software simulations before hardware is available for comparison. Problems involved in comparing the results of the silicon and software result in delayed characterization and a long time to market for the development cycle. With conventional solutions, stepping through tests on both hardware and software models simultaneously is not possible. Comparing hardware tests with RTL simulations during functional verification and debug stages is slow and unwieldy and presents a bottleneck to the debug and correction process.